From: http://www.rcmp-grc.gc.ca/html/tss-2-e.htm
+  Thanks to the Royal Canadian Mounted Police  +

5. HARDWARE SECURITY / 5.1 Administration / 5.1.1 Configuration/Inventory / 5.1.2 Contracting / 5.2 Security Features / 5.2.1 Prevention Features / 5.2.2 Detection and Surveillance / 5.3 Hardware Maintenance and Support / 5.3.1Routine Maintenance / 5.3.2 Problem Resolution / 5.4 Quality Assurance / 5.4.1 Support Facility / 5.4.2 Change Control / 6. COMMUNICATIONS SECURITY / 6.1 Administration / 6.1.1 General / 6.1.2 Separation of Duties / 6.1.3 Contracting / 6.1.4Inventory / 6.1.5 Departmental Standards / 6.1.6 Configuration / 6.2 Communications Maintenance and Support / 6.2.1 Routine Maintenance / 6.2.2 Problem Reporting / 6.2.3 Change Control / 6.2.4 Operational and Control Procedures / 6.2.5 Detection and Surveillance / 6.2.6 Prevention / 6.3 Communications Software / 6.4 Protection of Information in the Communications Environment / 6.4.1 General / 6.4.2 Designated Information / 6.4.3 Classified Information / 7. SOFTWARE SECURITY / 7.1 Administration / 7.1.1 Separation of Duties / 7.1.2 Inventory / 7.1.3 Security Review / 7.2 Design, Development, Maintenance, Quality Assurance and Acceptance Testing / 7.2.1 System Development Life Cycle Standards / 7.2.2 Change Control / 7.2.3 Problem Reporting / 7.2.4 Software Library Control / 7.2.5 Quality Assurance and Acceptance Testing / 7.3 System Software / 7.3.1 Configuration / 7.3.2 Identification / 7.3.3 Isolation / 7.3.4Access Control / 7.3.5 Integrity / 7.3.6 Availability / 7.3.7 Surveillance / 7.4 Data and Database Administration / 7.5 Applications Software / 7.5.1 Identification / 7.5.2 Isolation / 7.5.3 Access Control / 7.5.4 Integrity / 7.5.5 Surveillance / 7.5.6 Fourth-Generation Languages / 8. OPERATIONS SECURITY / 8.1 Administration / 8.1.1 Separation of Duties / 8.1.2 Mode of Operation / 8.2 System Access and Authorization / 8.3 Procedures and Controls / 8.3.1 Operating Procedures / 8.3.2 Input and Output Controls / 8.3.3 Detection and Surveillance / 8.4 Media / 8.4.1 General / 8.4.2 Media Library / 8.4.3 Inventory / 8.4.4 Identification / 8.4.5 Markings / 8.4.6 Disposal/Re-use / 8.5 Contingency Measures / APPENDIX OPS-1 -CLASSIFICATION/DESIGNATION MARKING ON MEDIA OR DISPLAYS / APPENDIX OPS-II -MEDIA SANITIZATION / APPENDIX OPS-III -RE-USE OF MEDIA IN THE SAME ENVIRONMENT WHERE CONFIDENTIALITY IS A CONCERN / REFERENCES

5.HARDWARE SECURITY

5.1 Administration

5.1.1 Configuration/Inventory

1. A chart of the current hardware configuration, identifying all hardware units and interconnections (e.g. CPU, peripheral devices, channels, controllers, etc.) shall be maintained and reviewed at least annually or, as warranted, when changes are made.
2. A current hardware inventory shall be maintained and should identify: manufacturer/supplier, model number, serial number, revision levels, micro-code levels, and ownership.
3. Where availability is a concern, the current minimum hardware configuration to support critical applications shall be identified and documented.
4. The responsibility for the maintenance of hardware records shall be assigned and documented.
5. A current copy of the hardware records (both operational and critical minimum configurations) shall be kept at an offsite location.

5.1.2 Contracting

1.Contracts shall specify the security requirements which apply to the hardware and related services controlled by a contractor, such as:

• release of information by the department:
• need-to-know principle;
• release of information by the contractor:
• configuration details;
• information processed by the hardware;
• protection of data:

• disposal techniques for media;
• procedures for maintenance, problem resolution, configuration control and change control; and

• service levels required:
  • define maintenance windows;
  • identify critical hardware;
  • define contingency plans.

2.Contracts shall include a configuration chart agreed upon by the department and the contractor.

3.Any configuration changes made during the period of the contract shall be documented, reported, reviewed, and approved prior to implementation.

4.Any configuration changes made during the period of the contract shall not reduce the level of security provided.

5.2 Security Features

5.2.1 Prevention Features

1. Where locks for hardware are available, they should be maintained in a secure operating position during normal operation.
2. Remote diagnostic access shall be controlled at all times.
3. All essential IT equipment left powered up and unattended shall have an automatic power-down capability, which will respond to environmental conditions outside the specifications detailed by the supplier, e.g. over-temperature, over and under voltage and humidity.
4. Where control keys/buttons are exposed, they should be protected from inadvertent operation, e.g. disk drive start/load buttons, write lock buttons, start buttons.
5. Systems processing particularly sensitive designated information or above, using authorized remote input/output (I/O) units shall be capable of uniquely identifying each user or unit by hardware means or other alternatives such as:

• smart card;
• dedicated communications, if the I/O units are contained within secure zones;
• approved encryption methods; or
• manual intervention.

(Note: Any changes to the hardware mechanism shall be possible only by replacing that mechanism.)

6.A TRA should be used to determine if TEMPEST-compliant equipment or alternate methods approved by the COMSEC authority are necessary to process classified or designated information.

7.The combination of hardware and software features or techniques should provide an environment capable of isolating and protecting users. As a minimum, the features or techniques should provide for:

• a set of privileges restricted to the system software which are not available to the user;
• control of computer system privileges, protective features, and controls such that only the system software may effect changes;
• use of only the system software to execute a halt or physical I/O instruction; and
• positive action when confronted with an undefined instruction bit pattern, illegal memory request (out of bounds to the current process), or hardware errors. Such action may include generating an interrupt.

8.The system's protective mechanisms shall be checked periodically to ensure they are functioning properly. This could include checking the capability of the system to prevent unauthorized:

• access to the system,
• access to data resources,
• access to residual data,
• use of privileged capabilities, and
• read/write capability outside allocated memory bounds.

5.2.2 Detection and Surveillance

1.The system should produce hardware maintenance logs containing, as a minimum, records of:

• machine checks,
• instruction or command retries,
• data transfer retries,
• abnormal environmental conditions,
• power fluctuations/failures, and
• any other error conditions.

2.Systems shall detect and react appropriately to secondary storage device errors. Such action should include recording the event.

5.3 Hardware Maintenance and Support

5.3.1 Routine Maintenance

1. Contracted maintenance personnel with access to equipment processing classified or designated information shall be supervised by someone responsible to the department with sufficient background, training or qualifications to understand the risks associated with the work being done and provide assurance that only authorized access to sensitive information or assets takes place.
2. Maintenance of TEMPEST-compliant equipment shall be performed only by trained TEMPEST maintenance personnel.
3. Procedures shall be documented and implemented to ensure that each use of system remote link-up for manufacturer's technical support shall be specifically authorized.
4. Departments shall prevent unauthorized access to sensitive information when remote diagnostic access is required.
5. Procedures for hardware equipment maintenance, consistent with the manufacturer's recommendations, shall be documented, implemented, and reviewed annually.
6. Records of all hardware maintenance activity shall be retained for a minimum of one year.

5.3.2 Problem Resolution

1. Procedures shall be developed, documented and implemented for reporting, recording, tracking and resolving hardware problems.
2. Hardware problems affecting security shall be immediately reported to the IT security coordinator.
3. A contact list identifying operations, field services, software services, and data communications personnel should be maintained.
4. All hardware equipment faults logged manually or by the system shall be brought to the attention of both the staff responsible for the operation of the system and the equipment maintenance staff.
5. Where availability is a concern, escalation procedures shall be developed and documented specifying problem priorities, actions to be followed and conditions for escalation.
6. Records shall be maintained of all hardware equipment faults and the action taken to resolve them. These records and their resolutions shall be retained for a period of one year.

5.4 Quality Assurance

5.4.1 Support Facility

1. Where availability is a concern, alternate power sources shall be installed to ensure the availability requirements are met.
2. Where data integrity is a concern, a stable power source and ground facilities consistent with the manufacturer's specifications should be provided, e.g. an uninterruptible power supply (UPS) facility or power distribution unit which provides monitoring and clean stable power.
3. System input power shall be checked at least annually to ensure it meets the manufacturer's specifications.
4. System grounding shall be checked at least annually to ensure it meets the manufacturer's specifications.
5. Where a UPS is used, all hardware devices required for continued operation shall be powered through the UPS, e.g. remote terminal servers, remote printers, air conditioning for hardware operation, heating for cooling tower, lights. Consideration should also be given to emergency environmental facilities in the support and user areas.

Note: The UPS should shut off power to the system (file server or small system) in the event of fire or conditions exceeding specified environmental requirements.

5.4.2 Change Control

1.Responsibility for change control functions shall be assigned and documented, and shall include:

• maintenance activities,
• configuration changes,
• equipment modifications, and
• micro code modifications.

2.All hardware modifications, maintenance activities and physical re-configurations shall be authorized.

3.Additions, deletions or alterations to an existing system shall be reviewed to ensure that the intended security profile of the system is not compromised.

4.All changes to hardware shall be centrally controlled and documented.

5.The following documentation shall be retained onsite:

• specifications,
• current manuals,
• log records, and
• revision levels.

6.COMMUNICATIONS SECURITY

6.1 Administration

6.1.1 General

1. The assignment of network access privileges and control of proxy accounts and default network accounts for all network users shall be centrally controlled, authorized and documented.
2. A security audit of communications shall be conducted annually to review the implementation and effectiveness of the security features and access controls to systems and data resources.
3. Departments are required to conduct a TRA of system interconnections, communications components and the network itself. This TRA shall include the department's total communications network.
4. Communication systems features that address confidentiality, integrity and availability requirements shall be commensurate with the requirements of the application, e.g. authentication, error detection and correction, and alternate routing.

6.1.2 Separation of Duties

1.The following communications duties should be kept distinct where possible:

• programming,
• operations,
• maintenance,
• software changes,
• hardware changes, and
• network changes.

6.1.3 Contracting

1.Contracts shall specify the security requirements which apply to the communications equipment, network and related services controlled by a contractor. Contracts should be reviewed annually to reflect changes in requirements. As a minimum, contracts should address the following areas:

• release of information by the department:
  • need-to-know principle;

• release of information by the contractor:
  • configuration details;
  • information flowing in the network;

• protection of data:
  • disposal techniques for recorded network information;
• procedures for line monitoring, maintenance, problem resolution, configuration control and change control;
• TEMPEST and encryption requirement;
• transportation of COMSEC documents; and

• service levels required:
  • define maintenance windows;
• identify critical circuits;
• define contingency plans.

2.Communications contracts shall include a communications configuration chart and all design changes agreed upon between the department and contractor.

3.Any configuration changes made during the period of the contract shall not reduce the level of security provided to the classified, designated, or otherwise valuable information to be transmitted or received.

4.Any configuration changes made during the period of the contract shall be reported, reviewed and approved prior to implementation.

6.1.4 Inventory

1. Responsibility for the maintenance of inventory records shall be assigned and documented.
2. A current communications inventory shall be maintained and reviewed at least annually. Documentation should indicate whether an item is owned, rented or leased and the date of the last change. The inventory should identify:

• communications hardware and services, including:
  • circuits, lines or connections assigned, including the identification of the supplier;
• the location of the physical termination of the circuits and lines;
• media used (e.g. coaxial, fibre, unshielded twisted pair);
• the circuit or line status (assigned or available);
• the level of security classification or designation of each circuit or line;
• hardware identifiers of remote input/output units;
• communications hardware (document model number and serial number), e.g. modems, dial-ins, concentrators, packet switched devices, encryption devices, and data switches;

·

• communications software and data, including:
  • software programs,
  • configuration database and files (libraries),
  • software procedures (e.g. Command Files),
  • software utilities,
  • security-relevant components,
  • licence numbers, and

·

• communications networks, including:
  • devices, e.g. servers, routers, gateways, bridges;
• protocol and level;
• network operating systems and applications software;
• network media and transmission methods;
• identification of node names (document: name, network address, type, location, responsible manager); and
• security-relevant network applications, features and items.

3.Inventory records for each communications software item should include the following:

• security classification or designation;
• whether or not the item is considered privileged or powerful;
• the quantity and their locations;
• identification of owner, custodian, authorized user and maintainer; and
• date created or modified and version/level number.

4.Communications terminations and/or circuits shall be identifiable by labels. Such labels shall be affixed on or near the equipment or on a diagram kept near the equipment. Cables should be labelled with unique identifiers.

5.Inventory items which are necessary for, or could affect, the system's protective mechanisms shall be assigned and marked with the security classification or designation of the most sensitive assets processed or transmitted by the system.

6.1.5 Departmental Standards

1. Departmental communications standards should be documented, maintained, reviewed annually and marked with an issue date.
2. The responsibility for departmental communications standards should be assigned and documented.
3. Where departmental communications standards are not followed as specified, the differences should be documented, including:

• cable pin configurations (show pinouts and colour coding);
• circuit/line options;
• labelling conventions:

- speed;

• parity;
• asynchronous or synchronous;
• character length;
• data communicating equipment (DCE) or data terminating equipment (DTE);
• number of logical links;
• protocol level;

· line cards/units:

• jumper options;
• programmable read-only memory (PROM) levels noting any special options;

· soft options used in intelligent network nodes, data switches, multiplexors, local area networks, etc.:

• various options chosen for each unit model;
• any critical parameters;
• closed user groups;
• classes of devices; and

· manufacturer's specifications and user documentation.

4.A current copy of the departmental communications standard should be kept at an offsite location.

6.1.6 Configuration

1. A chart of the current IT communications configurations shall be maintained, reviewed at least annually and marked with an issue date.
2. The communications configuration chart shall include hardware components and classes of interconnections used to establish, maintain and terminate communications. In addition, configuration charts should highlight exceptions to a departmental communications standard.
3. This chart should describe any special status and/or protection requirements, e.g. control terminals and access privileges associated with lines and circuits.
4. Where availability is a concern, the minimum configuration to support critical applications shall be identified, documented, and reviewed at least annually.
5. A current copy of the configuration (both operational and critical minimum) shall be kept at an offsite location.

6.2 Communications Maintenance and Support

6.2.1 Routine Maintenance

1. Responsibility for all maintenance activity shall be assigned.
2. Where access to classified or designated information is possible, contracted maintenance personnel shall be supervised by someone responsible to the department with enough background, training or qualifications to understand the risks associated with the work being done and provide assurance that only authorized access to sensitive information or assets takes place.
3. Records of all communications maintenance activity shall be retained for one year.
4. The use of communications test equipment, privileged and powerful communications software utilities, network monitoring tools and diagnostics for monitoring the network shall be authorized and controlled.
5. Magnetic recordings of communications monitoring shall be disposed of or sanitized using an approved technique. These techniques are described in the Operations Security chapter (Appendixes OPS-II and OPS-III).

6.2.2 Problem Reporting

1. Procedures shall be developed, documented and implemented for reporting, recording, tracking and resolving communications problems.
2. Records of problems and their resolutions shall be retained for a period of one year.
3. Communications problems affecting security shall be immediately reported to the IT security coordinator.
4. A contact list identifying communications support personnel, field service personnel, communications software services personnel, data communications vendors and telecom carriers shall be maintained.
5. Where availability is a concern, escalation procedures shall be developed and documented specifying problem priorities, actions to be followed and conditions for escalation.

6.2.3 Change Control

1.Responsibility for all aspects of change control functions shall be assigned and documented, and shall include:

• maintenance activities,
• configuration changes,
• equipment modifications, and
• software changes.

2.No changes shall be made to cryptographic equipment without prior approval of departmental COMSEC authorities.

3.All changes to communications equipment, communications software and network configurations shall be centrally controlled and documented.

4.The following documentation with respect to modifications should be retained onsite:

• specifications,
• updated manuals,
• configuration charts, and
• log records.

5.Additions, deletions or alterations to an existing system shall be reviewed to ensure that the intended security profile of the system is not compromised.

6.2.4 Operational and Control Procedures

1.Procedures governing the communications operations environment including multiple systems or networks shall be developed, documented and implemented and should include the following:

• communications start-up;
• communications shut-down;
• equipment operation;
• enabling/disabling/switching specific communications links/lines/ports;
• backup procedures/requirements, e.g. configuration data and software;
• maintenance;
• handling of sensitive material;
• emergency situations;
• communications logs review;
• the use of network performance monitoring and reporting; and
• the use of network management systems utilities.

2.Communications equipment, excluding user terminals, shall be operated only by authorized personnel.

3.Where multiple systems or multiple networks are involved, centralized policy and procedures shall be developed, documented and implemented for the network interconnection. These should include:

• assignment of a centralized network coordinator,
• configuration and change control guidelines,
• network performance monitoring and reporting,
• network security policy and procedures,
• network applications,
• problem reporting and escalation, and
• technical support.

6.2.5 Detection and Surveillance

1.Communications facilities shall be monitored for discrepancies, such as:

• protocol errors;
• inconsistent communications identification data as related to hardware identification and polling responses;
• sequence errors;
• status and error alarms;
• data inconsistencies;
• communications access control errors; and
• errors in network applications, e.g. E-mail, Electronic Data Interchange (EDI), file transfer, proxy accounts, routing.

2.Tests of security features shall be conducted periodically to ensure communications controls have not been compromised or misused. Results of these tests shall be recorded for audit and quality assurance purposes.

3.Where integrity of information is of concern (e.g. funds transfer), records shall be kept to ensure accountability of information throughout the communications system network, including intermediate locations, such as nodes, concentrators, network monitors, front ends, switches, gateways and routers.

4.Security logs, documents and records shall be retained for one year.

5.Change control records shall be kept for a minimum of one year for problem and security incident analysis.

6.2.6 Prevention

1.Systems should be capable of recognizing active communication links with users, so that links can be disconnected in response to recognized incidents or in order to reconfigure systems.

6.3 Communications Software

1.Where a department develops communications software, all software safeguards documented in Chapter 7, Software Security, shall apply.

6.4 Protection of Information in the Communications Environment

6.4.1 General

1. Direction and guidance for COMSEC shall be obtained from the COMSEC authority.
2. Where encryption is required, the COMSEC authority shall select the approved encryption technique.
3. Keying material for encryption devices shall be:

• obtained from the COMSEC authority; and
• handled, stored, used, protected and accounted for in accordance with approved COMSEC procedures.

4.Passwords and other security-related information shall be encrypted.

6.4.2 Designated Information

1. The transmission of all extremely sensitive designated information (Protected C) shall be protected by approved cryptography or other approved COMSEC measures.
2. Where supported by a TRA, other sensitive designated information (Protected A and B) should be protected by controlled communications measures and/or other COMSEC measures, such as:

• dedicated circuit;
• line encryption;
• hardware identifier in the terminal;
• external communications access control devices, e.g. smart cards, tokens;
• Closed User Group; and
• dial connection initiated by the host site.

3.Data which is not classified, but, as determined by a TRA, warrants protection against disclosure through compromising emanations, should be protected using TEMPEST methodology.

4.Where cryptography is employed, such equipment shall be operated and maintained only by trained, authorized and appropriately-cleared personnel.

6.4.3 Classified Information

1. Communications systems processing classified information shall be installed, operated, maintained and protected in accordance with appropriate COMSEC Manuals (CID 01/8, CID 01/10, CID 09/7A and operation doctrines).
2. Where warranted by a TRA, departments shall use TEMPEST-compliant equipment or other approved methods to protect against compromising emanations, for telecommunications or electronic processing or storing of classified information.
3. Where steps have been taken to protect against compromising emanations, the COMSEC authority shall ensure periodic tests and/or inspections are conducted to confirm the continuing integrity of the emanation protective measures.
4. Where there is a change in the sensitivity/classification of information being processed, stored or transmitted, or a change in the TRA affecting TEMPEST- compliant measures, the COMSEC authority shall review the existing compromising- emanation protective measures to ensure their adequacy.
5. The transmission of all classified information shall be protected by approved cryptography or other approved COMSEC measures.
6. Where cryptography is employed, such equipment shall be operated and maintained only by trained, authorized and appropriately-cleared personnel.

7.SOFTWARE SECURITY

7.1 Administration

7.1.1 Separation of Duties

1.To the degree practical, the following functions shall be assigned to different individuals in separate organizational entities:

• systems programming,
• systems administration,
• database administration,
• application programming,
• quality assurance and acceptance testing, and
• program library maintenance and control.

7.1.2 Inventory

1. The responsibility for the maintenance of inventory records shall be assigned and documented.
2. Inventory records for production software and data assets shall be maintained. Inventory items should include:

• systems software,
• database software,
• application software,
• access control software,
• software utilities,
• software procedures and command files,
• program and procedure libraries and directories,
• databases and data files, and
• operational configuration parameters.

3.Inventory records for each item should indicate:

• security classification or designation;
• whether the item is considered privileged or powerful software;
• warranty/maintenance conditions;
• the number of copies or valid users along with their physical locations;
• the owner, custodian, authorized user and maintainer; and
• a creation/modification date, version/level number and any special modifications.

4.Inventory items providing or affecting the protective mechanisms of the system shall be assigned a security classification or designation, commensurate with the most sensitive information and assets on the system.

7.1.3 Security Review

1. Departments shall ensure that the use of privileged or powerful software is authorized, monitored and reviewed.
2. Departments shall conduct an annual security review of software items and data. The review should include:

• change control practices and procedures,
• compliance with documentation standards,
• operating system and application program library controls,
• the effectiveness of logical access controls,
• controls for the use of privileged or powerful software,
• integrity and availability controls,
• software and data-related aspects of contingency measures, and
• accuracy of inventory.

7.2 Design, Development, Maintenance, Quality Assurance and Acceptance Testing

7.2.1 System Development Life Cycle Standards

1. Software acquisition procedures shall be documented and implemented to establish and maintain a level of confidence appropriate to the sensitivity of the information to be stored or processed.
2. Procedures, often referred to as the System Development Life Cycle (SDLC), shall be documented and implemented to guide and control the design, development, approval, testing, documentation, implementation, maintenance and protection of production software and data items.
3. The SDLC should include the following phases:

• preliminary analysis or feasibility study,
• systems analysis,
• general design,
• detail design,
• development,
• quality assurance and acceptance testing,
• implementation, and
• post-implementation maintenance and review.

4.The SDLC shall include documented provisions, limitations and required authorizations for bypassing one or more of the established phases.

5.A review of the security requirements and compliance with IT security standards and statements of sensitivity shall be conducted and signed off by an appropriate authority during each phase of the SDLC.

6.The IT security coordinator(s) should participate in all phases of the SDLC and the security requirements review process.

7.For systems with high integrity concerns, the appropriate auditors should be included in the security requirements review process.

7.2.2 Change Control

1. Responsibility for maintaining change control records shall be assigned and documented.
2. Procedures for controlling changes to production software shall be documented and implemented. The change control procedures should include the mechanisms for:

• requesting changes,
• recording and tracking outstanding requests,
• approving requests,
• testing and documenting changes, and
• incorporating changes.

3.Production software shall, where possible, be maintained in both source and executable form. Production software shall be considered to include:

• operating systems and supporting utilities,
• database management systems,
• application software,
• access control software, and
• operational parameters.

4.Third party proprietary or custom-developed software shall, where possible, be acquired and maintained in both source and executable form.

7.2.3 Problem Reporting

1. Responsibility for maintaining and tracking problem reports shall be assigned and documented.
2. Procedures shall be documented and implemented for the reporting, monitoring, and resolution of software and data discrepancies. As a minimum, date, time and nature of the problem shall be recorded.
3. Software or data problems which could affect security shall be immediately reported to the IT security coordinator.
4. Priority shall be given to the resolution of software and data problems that affect security.

7.2.4 Software Library Control

1.Responsibilities for software library maintenance and control shall be assigned, documented and include:

• custody;
• access control for production, audit, and change control purposes;
• onsite and offsite backups; and
• maintenance of the records of access and changes.

2.Software library backup procedures shall be documented and implemented to provide the capability of restoring specific versions of software elements.

3.Update privileges shall be restricted to individuals responsible for:

• software development, in the case of development program libraries;
• quality assurance and acceptance testing, in the case of acceptance testing libraries; and
• transferring software to production status, in the case of production libraries.

4.Software management and distribution procedures shall be documented and implemented for distributed and remote systems to ensure:

• all software distribution is authorized;
• licensing agreements concerning usage and disposal are observed; and
• software and data are backed up and updated in a consistent and controlled manner.

7.2.5 Quality Assurance and Acceptance Testing

1.Responsibilities for quality assurance functions shall be assigned and documented, and should include:

• development and implementation of acceptance test standards and criteria,
• performance of quality assurance and acceptance testing,
• reviewing and reporting on these test results to ensure established test criteria are met prior to implementation, and
• custody and retention of test results.

2.Production data should not be used for testing purposes. When it is not feasible to create test data, copies of production data may be used provided the confidentiality requirements of the production data are satisfied.

3.Software testing should be conducted in an environment separate from the production system.

4.Where security concerns warrant, testing should include:

• line-by-line code reviews, and
• comparison checks of executable routines.

5.When software is transferred to acceptance testing or production status, the transferred source code, if available, shall be re-compiled/re-assembled within the recipient libraries to ensure compatibility between source and executable code.

6.Where practical, all software shall be examined for malicious codes.

7.3 System Software

7.3.1 Configuration

1.Parameters and options required to start up the operating system, supporting utilities, third party proprietary and custom software products shall be established and documented, based on configuration and security requirements.

7.3.2 Identification

1.Systems should have the capability of identifying discrete elements including:

• users,
• data,
• media,
• software programs,
• hardware components, and
• communication links.

2.When data is written on removable media, system capabilities shall be used for writing and verifying machine-readable labels.

3.System capabilities shall be used to verify the identity of volumes and files recorded on machine-readable labels or file systems against information contained in access requests.

7.3.3 Isolation

1. Passwords or similar authenticators shall be obscured by one-way encryption.
2. Operating systems and access control systems, with an evaluated level of trust appropriate to the sensitivity of the data, shall be implemented as required to restrict access to system and data resources.
3. Where users have different duties and access rights, controls, such as restricted transaction processing or captive accounts, shall be implemented to restrict users to specific required functions.
4. To provide for user-user and user-computer system isolation in a multi-user environment, the following privileges shall be restricted and monitored:

• changing computer system privileges or controls,
• changing protective features or parameters affecting another user,
• halting the computer system,
• allocating system and data resources for personal use, and
• inhibiting the allocation and sharing of system and data resources.

5.Where confidentiality is a concern, and users do not share a common need-to- know, the contents of erasable media shall be obscured using an approved technique at the time the file space is released for reuse or destruction.

6.The system shall automatically terminate or re-authenticate an interactive user's session after a predefined period of inactivity.

7.Where confidentiality is a concern, display screens and all associated memory shall be cleared upon user sign-off or after a predefined period of inactivity.

8.Systems shall inhibit or overwrite authentication information on display screens.

9.User authentication information shall not be included on any form of computer output.

7.3.4 Access Control

1. Based on requirements documented in system statements of sensitivity, an access control system shall be implemented to control and monitor access to the system and data resources.
2. At each successful sign-on, the user should be informed of the date and time of the last successful sign-on and any subsequent failed sign-on attempts.
3. Access to system and data resources shall be based on user identity and only be granted based on predefined authorization.
4. Access control mechanisms shall control access to system and data resources and shall be based upon the user's functional requirements and authorization. User privileges could be restricted by:

• controlling user read, write, create, delete and execute capabilities;
• implementing access control lists;
• implementing capability lists; and
• controlling hierarchical authorization such as owner, group, system and universe.

5.When access to system and data resources is denied, no indication of the specific reason for denial shall be provided.

7.3.5 Integrity

1. Recovery routines and procedures shall be designed to minimize the possibility of mis-routing interrupted transactions or transmissions.
2. Where changes of processing state are required, procedures shall be documented and implemented to ensure the integrity of the operating system and supporting software which is used to process classified information.

7.3.6 Availability

1.For systems with critical availability requirements:

• redundant hardware, software and communications shall be used to process the transactions simultaneously;
• hardware and/or software techniques shall be used to detect hardware/software failures in the primary and backup systems;
• the backup system shall automatically switch the required hardware, software and communications equipment to primary status upon failure of the primary system; and
• the application software program processing the transactions on the primary system shall be logically different from the backup system.

7.3.7 Surveillance

1.The system's surveillance and protective mechanisms shall be tested at least annually, or following changes to security-relevant software, to ensure continued capability of the system to prevent unauthorized:

• access to system and data resources;
• access to residual data;
• use of privileged capabilities; and
• read or write from outside allocated memory bounds.

2.The system shall record security-relevant events. These events should include:

• job or process status (entry, initiation, completion, deletion, restart, and abort);
• file, volume, and database accesses (open, close, create, delete, rename);
• communications device connect, disconnect and re-configuration;
• network status messages;
• user sign-on and sign-off;
• system operator commands and responses;
• system and subsystem status messages (start-up, shutdown, abort);
• system-generated messages or requests regarding configuration changes;
• changes to system logging facility status (start, stop, alter, print, dump, delete, rename and overflow);
• changes to access control information;
• changes to lists of authorized users;
• detected security incidents; and
• use of privileged or powerful software.

3.For each security event, the following information, if applicable, shall be recorded:

• nature and type of incident,
• date and time,
• user identification,
• device identification,
• job or process identification,
• identification of resource accessed,
• mode of access, and
• configuration details.

4.When logging security-relevant information whose confidentiality must be protected based on the need-to-know principle, the entry shall specify only that a particular type of event has occurred.

5.Where log records are machine-readable and of sufficient volume to make manual recognition of security-relevant events impractical, software routines shall be used to highlight security-relevant events.

6.When a security-related event is detected, a highlighted message shall be routed to a system console or printer for further analysis.

7.When a severe security-related event is detected, an audible or visual alarm shall be immediately activated.

7.4 Data and Database Administration

1.Responsibilities for data and database administration shall be assigned and documented, and shall include:

• access control,
• data dictionary,
• definition and creation,
• integrity and audit, and
• backup and recovery.

2.The implementation of the database shall maintain isolation of information based on sensitivity and the need-to-know principle.

3.Database audit checks shall be conducted to verify the logical and physical consistency of the database and identify discrepancies such as lost records, open chains and incomplete sets.

4.A data dictionary should be used to document, standardize and control the naming and use of data.

5.Database maintenance utilities that bypass controls shall be considered to be privileged and powerful software. Use of these utilities shall be restricted and monitored.

6.The system should be capable of automatically recovering the database following a system or application software failure.

7.Where availability is critical, duplicate databases shall be maintained on separate physical devices and all database maintenance transactions shall be performed simultaneously on both databases.

8.Where confidentiality is a concern, automated or manual controls should be implemented to protect against unauthorized disclosure by means of inference search techniques.

9.Where the integrity of records stored on the database is a concern, data integrity verification techniques, such as message and record authentication coding or hash total techniques, shall be implemented.

10.Where the auditability and authorization of records stored on the database is a concern:

• the user identification and authentication process shall positively identify the authorizer;
• the user identification of the authorizer and data entry person shall be retained on the transaction record; and
• all critical data elements, including transaction date and time, authorizer and data entry user identifiers, shall be included in the data integrity verification process.

7.5 Applications Software

7.5.1 Identification

1. Where differing access privileges exist within an application, users shall be uniquely identified.
2. Application access control mechanisms should use the user identification obtained by the system during initial sign-on, rather than an alternate or subsequently obtained identifier.
3. A standard naming convention for applications, programs, databases, files and data elements shall be used to facilitate the identification of software assets.

7.5.2 Isolation

1.Where differing access privileges exist within an application, users shall be restricted in their view of the data, through use of:

• the captive user concept; or
• data file, record, and element protection.

7.5.3 Access Control

1.Where differing access privileges exist within an application, access control mechanisms shall be implemented to restrict access to application and data resources in accordance with users' functional requirements and authorization.

7.5.4 Integrity

1.For systems with high integrity requirements:

• the application's protective mechanisms shall be tested following changes to security-relevant software;
• applications shall incorporate checks to ensure the validity and correctness of input data or parameters (such as edit routines, range/reasonableness checks, batch totals, sequence numbers, check-sums, hash totals, error-correcting codes);
• the system design shall ensure that data can be recovered automatically or with the assistance of the data originator following computer crashes;
• the system design shall include backup requirements to ensure data can be fully recovered, taking into account the length of time an error may remain undetected;
• a copy of each transaction processed shall be transmitted and stored immediately at an offsite location;
• the system design shall ensure that the output of the process is checked against control records (such as batch totals, record/block counts, check-sums, hash totals, sequence checks);
• control records shall be output at intervals during the process and reviewed prior to acceptance of the process output; and
• output processes shall ensure the acknowledgement of receipt of information.

7.5.5 Surveillance

1.Where auditability of access to sensitive information is a concern, the system or application logs should include the contents of the data accessed by the user as well as the identification of the recipient.

7.5.6 Fourth-Generation Languages

1.Controls shall be in place to ensure the confidentiality, integrity and availability requirements of the system cannot be compromised through the use of a fourth- generation language. Controls shall include:

• restricting access to production data and resources;
• logging and monitoring access to production data and resources; and
• limiting system resource consumption, such as processing time and the number of database reads or writes.

2.All fourth-generation language programs which modify data shall be developed and tested in a separate environment.

8.OPERATIONS SECURITY

8.1 Administration

8.1.1 Separation of Duties

In this chapter, the term "operations personnel" refers to the personnel responsible for the use and control of a system. "System" includes mainframes, mini-computers, networks and workstations.

1. Operations personnel shall be prohibited from making changes to computer programs (executable and control code) without authorization.
2. Operations personnel shall not make, or be responsible for, input additions or error corrections to production data unless documented policy has been issued outlining the circumstances under which these actions will be permitted and the audit controls which will apply.
3. Hardware, excluding user workstations, being used to process production shall be operated only by operations personnel. In an emergency situation, non-operations personnel may operate hardware under the direct supervision of operations personnel.
4. When a data control function is established, it should consist of a separately staffed unit whose duties are designed to provide separation between users and operations personnel. In certain circumstances, further separation of duties within the data control function may be required.
5. Operations personnel shall be prohibited from initiating their own jobs without prior authorization.
6. Departments should, for control purposes, ensure there is a rotation of operators on sensitive applications.

8.1.2 Mode of Operation

1. In all instances where classified or designated information is processed in either public or private sector facilities, the mode of operation used shall be chosen and specified in accordance with Chapter 1 of this document.
2. When it is necessary to change the mode of operation, the following precautions shall be taken:

• disconnect all communications lines which do not comply with the requirements of the mode of operation to be used;
• sanitize the memory;
• disconnect any access path to data which is not specifically required to support processing of the new mode of operation;
• use a fresh copy of an appropriately-protected version of the operating system for the new system; and
• use an approved means to obscure the contents of all erasable media to be shared by the system.

3.When a remote system is unable to support the local mode of operation, the local system shall disable the communications link between them.

8.2 System Access and Authorization

1. All use of computing facilities shall be authorized.
2. Departments shall ensure that no access to IT systems and data is permitted without the user being uniquely identified. A user identifier by itself should not grant access privileges.
3. User identifiers should be designed to permit group level identification of individuals who have the same:

• level of security clearance;
• need to access the IT systems and data; and
• functional requirements.

4.Procedures shall be developed and implemented for the preparation, issue, change, cancellation and audit of user identifiers.

5.Access to system and data resources shall not be granted until the individual's identity has been authenticated, and authorized privileges have been confirmed, automatically or manually.

6.Where the authentication process uses unique authentication codes or passwords, such items shall be:

• generated, controlled and distributed in a manner which maintains the confidentiality and integrity of the authentication code;
• known only to the authorized user of the account;
• pseudo-random in nature or verified by an automated process designed to counter triviality and repetition;
• at least six characters in length;
• one-way encrypted;
• excluded from unprotected automatic log-on processes; and
• changed in accordance with the following minimum schedule:

7.Records concerning system authentication mechanisms, codes or passwords used to authenticate identities shall be provided the same level of security as the highest classification, designation, or sensitivity of data processed.

8.Authorization shall be obtained whenever a security feature normally used on the system cannot or will not be used. The actions taken in these circumstances shall be documented and reported as a security incident.

9.Workstations which have privileges over and above those of other devices on the system shall be controlled to ensure their use is authorized and audited.

8.3 Procedures and Controls

8.3.1 Operating Procedures

1.Procedures governing the day-to-day functions of the operating environment are required and should cover, as a minimum:

• power up/power down sequence,
• start up/shut down of systems (including operating system and applications),
• equipment operation,
• trouble reporting,
• security incident handling,
• operator-performed maintenance,
• operator commands,
• operator responses to systems and application program-generated messages,
• start and stop communications,
• backup and restore,
• sanitizing the system,
• sanitizing erasable media,
• disposal of unserviceable erasable media,
• emergency situations,
• shift hand-over,
• over-riding of security controls,
• recovery/restart,
• handling of classified/designated material,
• environmental support equipment, and
• setting and resetting the system clock.

2.Prior to accepting software that requires operator response:

• procedures shall be provided, and
• training shall be completed.

3.Verification procedures for backup, e.g. a compare or restore, shall be developed and implemented to ensure the backup was successful.

4.Sufficient generations (as defined in the application's statements of sensitivity) of backup data shall be maintained to ensure that data can be recovered.

5.Shift hand-over procedures shall ensure that operational continuity is maintained, and should include a shift overlap.

6.Procedures shall be developed and implemented to control the overriding of system security including authorization, control, audit and return to use of the security feature.

7.Procedures shall be developed and implemented to cover the transfer of the operational control of the hardware and software environment from the normal operations group to any other person or group such as system maintenance personnel.

8.The transfer of the operational control procedures shall include actions which minimize the possibility of any compromise of the confidentiality, integrity and availability requirements of the system and data resources.

9.When machine-readable labels are used on media, bypassing the label shall be prohibited, except for specific circumstances supported by written authorization.

10. When machine-readable labels are used, and bypassing label processing is authorized, mechanisms or procedures should be in place to ensure that the correct volume is mounted.

11. Accountability and control shall be provided for sensitive, pre-printed and computer-generated forms from the time of receipt or production until they leave the IT environment. Examples of these forms are visas, passports, cheques and warrants.

8.3.2 Input and Output Controls

1.When confidentiality or integrity of output is a concern, actions shall be taken to ensure that:

• jobs are only rerun or reprinted under strict controls and with prior authorization;
• output is delivered only to the owner or to a person who has been authorized to receive it; and
• receipts are obtained when output is delivered.

Integrity

1.Procedures shall be in place to ensure the accountability of data being input to a system. These procedures should include measures to provide accountability for:

• input materials received by operational units; and
• transactions or other data being input to the system locally or remotely.

2.An audit trail of transactions being input to a system should relate each specific transaction to the individual who entered it.

Note: This requires the identification of individuals using data entry devices and records that show who entered which transaction. Identification of the individual using a data entry device may be by means of logical identifiers and authenticators (account numbers and passwords) unless the probability of deliberate attempts to compromise the transactions is deemed to be high, in which case physical identification is required.

3.When data verification is performed, it should be done by an individual other than the person entering the data.

4.When no hard-copy authorization records are maintained, logs recording all details of transactions together with supporting authorizations shall be maintained and safeguarded.

Confidentiality

1.Actions shall be taken to ensure that:

• only the number of copies of output specified by the person generating the output is produced;
• distribution of all output is logged;
• unless sensitive information is deleted from a system dump, the dump is protected commensurate with the highest level of information on the system until it is destroyed or disposed of; and
• the appropriate security classification or designation is marked on all output.

2.Remote hardcopy or display devices shall be positioned to prevent observation by unauthorized personnel.

8.3.3 Detection and Surveillance

1. Records identifying each individual in the operations area shall be kept. Scheduled operations personnel are required, as a minimum, to sign in and out at the commencement and conclusion of each shift.
2. System logs should be checked at randomly selected periods to verify that all processing was authorized.
3. Where software metering is in use, usage logs should be reviewed to assist in the detection of unauthorized software use.
4. The IT security coordinator, or another person designated by the department, shall be responsible for the regular review of security logs and records to ensure that all responses to security incidents were correct and comply with existing procedures.
5. IT facilities should produce a report on the type and frequency of errors. The information in this report should be reviewed for security connotations by the IT security coordinator or designate.
6. All operator errors shall be reviewed and analyzed for security connotations.
7. Hardcopy logs and records that are used for accountability or control purposes should be designed so that the removal of records can be detected (e.g., paper log pages could be sequence numbered).
8. Security logs, records and documents used for accountability or control purposes shall be retained for at least one year.
9. Logs and security records shall be protected commensurate with the highest level of classification/designation of information on the system.

8.4 Media

8.4.1 General

1. Responsibility shall be assigned for the control and care of all removable media.
2. Procedures shall be developed and implemented for the handling, protection and accountability for all removable media entering, remaining within and leaving the IT environment.
3. The regular and proper maintenance of erasable media should be undertaken.
4. Where controlled access is a concern, information of different sensitivities should be maintained on separate physical devices to maintain isolation.

8.4.2 Media Library

1.Access to a media library shall be:

• restricted to authorized personnel, and
• logged and audited.

2.Records generated for accountability of IT media should include :

• media identifier,
• identification of owner,
• date and time of transaction, and
• details of transaction including appropriate authorization.

3.Unless an automated media management system verifies ownership, all write- protection mechanisms shall be enabled for media containing information to be retained when the media is removed from the drive.

4.Media write-protection mechanisms shall be disabled only by IT staff assigned responsibility for the control and care of removable media.

5.Procedures shall be developed and implemented to allow designated or classified removable IT media to be placed in a protected status and used only with written authorization.

6.No IT media shall be removed from the operations environment without the approval of a third party, specifically designated by the department.

7.When removable media is stored in offsite locations, controls shall be commensurate with the highest level of classification/designation of information contained on the media.

8.4.3 Inventory

1. The IT security coordinator shall be immediately advised of any discrepancy between the records pertaining to removable media and the authorized disposition of such media.
2. An inventory of all removable IT media under the control of the media library shall be carried out in accordance with the following minimum schedule:

• Top Secret- Monthly
• Secret - Quarterly
• Confidential- Quarterly
• Protected- Annually
• Other - Annually

3.The inventory of removable media should be carried out by a minimum of two individuals working together, one of them employed in an area independent of the media library function.

8.4.4 Identification

1. Procedures shall be developed and implemented to ensure that the identity of volumes and files of removable media is verified against the information contained in requests for access.
2. Procedures should be developed and implemented to ensure that all removable media contain machine-readable internal labels.
3. To verify the identity of the media, machine-readable labels should be read by the system when the media is mounted.

8.4.5 Markings

1. IT media shall be assigned a security classification or designation commensurate with the most sensitive information on the media.
2. The security classification/designation shall be clearly marked on all IT media in accordance with Appendix OPS-I.

Note: When every piece of IT media in a facility has an identical security classification or designation, the classification/designation level need be marked only when the media leaves the IT facility.

3.Ownership of all removable IT media shall be clearly indicated in eye-readable form on the media itself and on the containers used for such media when they are to be removed from the IT environment.

4.Backup media containing information owned or received by the department shall be stored on government-owned media.

8.4.6 Disposal/Re-use

1. Erasable media previously used to store classified/designated information shall not be released from the IT environment until the media has been sanitized using an approved erasure technique. Examples of such approved techniques are contained in Appendix OPS-II.
2. Erasable media and their containers shall be divested of all markings only after verification of the sanitization procedure.
3. When equipment containing media is to be removed from the IT environment for servicing, the techniques listed in Appendix OPS-II shall be applied.
4. Where confidentiality is a concern, erasable media that contain sensitive information and are to be retained for re-use or re-allocation within the same environment shall be erased or overwritten using one of the approved techniques listed in Appendix OPS-III.
5. Where disclosure is a concern, the contents of erasable media which have been used to store sensitive information shall be obscured automatically or manually before the media are used for any other reason.
6. Where confidentiality is a concern, procedures for securing materials used to produce sensitive output, such as printer ribbons, OPC cartridges, carbon paper, and mylar film, should be developed and implemented, to ensure these materials are:

• physically secured during silent hours,
• controlled when the output device is left unattended,
• disposed of in an approved manner (e.g. by burning or shredding), and
• suitably protected, including inventory control, while awaiting destruction.

8.5 Contingency Measures

1.Current copies of the critical operational data and material and a sufficient supply of the critical media resources to ensure the continued provision of the minimum essential level of service, as defined in the department's business resumption plan, shall be stored at an offsite location. These items should include:

• operating system software,
• utilities,
• applications system software,
• data,
• documentation,
• encryption keys,
• passwords, and
• forms.

2.An index of the resources which are stored offsite should also be stored at the offsite location and should contain:

• identification of the resources and data,
• names of the owners of the data, and
• the classification or designation of the data.

3.The operational requirements of the department's contingency plan shall be reviewed, at least annually, to ensure that all critical operational components, materials and resources have been identified.

4.Backup media and associated documentation consistent with contingency plan requirements shall be maintained onsite and offsite.

5.An up-to-date list of telephone numbers to be used in responding to contingencies and emergencies shall be readily available to operations personnel.

APPENDIX OPS-1

CLASSIFICATION/DESIGNATION MARKING ON MEDIA OR DISPLAYS

1. Printed Output

a) Top Secret and Secret

- top right of every page or torn-off segment of a roll; and

b)Confidential and Designated

- top right of face (cover) sheet.

Note: This can be done by program instruction, use of pre-printed stationery or manually.

Additional information on the control of printed output can be obtained from the Treasury Board Manual, Security volume, Chapter 2-1, Appendix D.

2. Display

• in eye-readable and continuously present form on the display unit; and
• with a warning on the display unit indicating the highest classification or designation of information for which the device is used.

Note: When every display unit has an identical security classification or designation, the classification/designation level need be marked only at the facility.

3. Computer - Output Micrographic (COM)

a) MICROFILM

• in plain language and eye-readable form on cartridges or cassettes,
• at the beginning and end of the film in plain language and eye-readable form, and
• at the centre of the top and bottom of each individual frame.

b) MICROFICHE

• envelopes clearly marked in plain language and eye-readable form,
• on the header line in plain language and eye-readable form, along with the fiche number and the total number of fiche (e.g. 1 of 5), and
• at the centre of the top and bottom of each individual frame.

4. Storage Media

- for non-removable and removable storage media, on the casing where feasible, and the outer container in plain language and eye-readable form.

Note: Formats not covered above should be handled by extension or analogy.

5. Marking

The following colour codes may be used to assist in denoting the security classification or designation of information within an IT facility:

APPENDIX OPS-II

MEDIA SANITIZATION

1. Media Types

a) Magnetic media are divided into types.

• Type I products are used to degauss magnetic media whose coercivity is no greater than 350 Oersteds (Oe).
• Type II products are used to degauss magnetic media whose coercivity is between 350 Oe and 750 Oe.
• Refer to the media manufacturer to determine the media type.

b) Coercivity of magnetic media defines the magnetic field necessary to reduce a magnetically-saturated material's magnetization to zero.

c) In addition to coercivity concerns, the sanitized media (for both Type I and Type II) shall have residual signal levels for the fundamental signal and all harmonics at a minimum of 90db below the saturated signal level after the completion of the degaussing cycle.

2. Degaussing Units

a) A current list of approved degaussing equipment may be obtained from the RCMP, IT Security Section.

b) The correct use of degaussing products will ensure that data is no longer retrievable.

3. Erasure Requirements

a) Non-removable magnetic media (drums, disks and disk packs)

- Must first be checked for correct functioning and then have all storage areas overwritten once with the binary digit ONE, once with the binary digit ZERO and once with a single numeric, alphabetic or special character, using for example the RCMP Magnetic Disk Media Overwrite and Inspection Utilities for IBM/PC.

- The current used in overwriting shall be at least equal to that used in recording the information and sufficient to override any peaks or valleys which may have occurred in the power source during the recording period. This overwrite current shall not be of such a strength as to damage or impair the equipment.

b) Removable magnetic media (tapes, cartridges, and disks)

- Must first be passed through a bulk eraser or tape degausser which, in both cases, has been approved for the media type and classification/designation.

c) Sanitization of Type I media using a permanent magnet:

• The recording surface shall be erased by exposure to a permanent magnet which has a field strength of at least 1500 Oe at the recording surface and which has been approved by the RCMP, Security Systems Section;
• The entire surface shall be wiped at least three times by non-uniform motion of the magnet.
• All tracks shall be covered by the centre of the magnet.

Note:A thin sheet of clear plastic (from 1 to 5 mils) should be used to prevent damage to the recording surface of drums, disks and disk packs when using a magnet to erase the media.

d) Magnetic core

- after being overwritten 1000 times with alternating 0 and 1 bits.

4. Destruction Methods

Destruction methods may be used to sanitize media permanently. These techniques must guarantee that the storage surfaces are completely destroyed. Examples of destruction methods are burning, acid baths, emery wheels, crushing and shredding. (Refer to "Physical and Environmental Security", TSSIT Chapter 4.)

NOTES

(1) Where a sanitization procedure is not practical, or media other than that identified above is a concern, advice should be requested from the RCMP, IT Security Section.

(2) Where Top Secret information has been resident on the magnetic media in excess of 48 hours, the RCMP (IT Security Section) should be contacted for the approved sanitization method.

(3) EPROMS should be destroyed unless they are to be reprogrammed and re-used within the same environment.

APPENDIX OPS-III

RE-USE OF MEDIA IN THE SAME ENVIRONMENT WHERE CONFIDENTIALITY IS A CONCERN

1. Removable magnetic media (tapes, cartridges, and disks)

- after a single overwrite at normal recording current level with a single alphanumeric character or bit pattern, or after being passed through an approved degausser or bulk eraser.

2. Non-removable magnetic media (drums, disks and disk packs)

- after first being checked for correct functioning and then having all storage areas overwritten once with the binary digit ONE or the binary digit ZERO at normal current level.

3. When the capability exists as an integral part of the storage sub-system, prior to re-using or re-allocating erasable media, an AC/DC erase should be applied to all data tracks after the tracks have been overwritten and the overwrite verified.

4. EPROMS should be destroyed unless they are to be re-programmed and reused within the same environment.

5. Any other approved technique.

REFERENCES

FEDERAL STATUTES

Access to Information Act

Financial Administration Act

Interim Policy Guide: Access to Information Act and the Privacy Act, Parts II and III

Interpretation Act

Official Secrets Act

Privacy Act

Public Service Employment Act

Public Service Staff Relations Act

Tenants Act

RCMP PUBLICATIONS

Guide to Threat and Risk Assessment for Information Technology (SIP 5), RCMP, November 1994

Construction Specification for Secure Room C (SSB/SG-23), March 1991

Construction Specification for Secure Room D (SSB/SG-22), March 1991

Guide to Preparation of Physical Security Briefs (SSB/SG-25), October 1992

Security Equipment Guide (SSB/SG-20), October 1992 (Distribution restricted to federal government departments and not available electronically.)

Standard for the Transport and Transmittal of Sensitive Information and Assets (SSR/SG-30), June 1994

TREASURY BOARD SECRETARIAT PUBLICATIONS

Security volume, Treasury Board Manual (Cat. No. BT52-6/3), commonly known as the "Government Security Policy" (GSP).

"Fire Protection Standard for Electronic Data Processing Equipment", Treasury Board Manual, Occupational Safety and Health, Chapter 3-3.

Federal Identity Program Manual, March 1990

COMMUNICATIONS SECURITY ESTABLISHMENT PUBLICATIONS

The Canadian Trusted Computer Product Evaluation Criteria, Version 3.0e (CID 09/19), January 1993 (Unclassified)

Controlled Cryptographic Items (CCI) Manual (CID/01/08), March 1992 (Unclassified)

INFOSEC Materiel Control Manual (CID/01/10), September 1991, Interim Release (Protected A)

COMSEC Installation Planning (TEMPEST Guidance and Criteria) (CID/09/7A), 1983, (English only)(Confidential)

Criteria for the Design, Fabrication, Supply, Installation and Acceptance Testing of Walk- In Radio Frequency Shielded Enclosures (CID/09/12A)(Unclassified)

OTHER GOVERNMENT DEPARTMENTS PUBLICATIONS

Guide to the Audit of Security (OCG Guide 406)

Industrial Security Manual, (Supply and Services Canada, 1992)

National Building Code of Canada (National Research Council)

Record Storage, FC 311(M) (Fire Commissioner of Canada)

PRIVATE AGENCY PUBLICATIONS

Underwriters' Laboratories of Canada Standards